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PARAMETRIC TRACE SLICING 

RELATED APPLICATIONS 

This application claims the benefit of U.S. Provisional 5 
Application No. 61/298,303, filed Jan. 26, 2010, entitled 
“Parametric Trace Slicing”, to Grigore Rosu, Feng Chen, and 
Patrick O. Meredith, which is hereby incorporated by refer- 
ence herein. 

GOVERNMENT LICENSE 

This invention was made with Government support under 
Grant Numbers CCF -0448501, CNS-0509321, and 
CNS-0720512 awarded by the National Science Foundation 
(NSF), and Contract Number NNL08AA23C awarded by the 
National Aeronautics and Space Administration (NASA). 
The Government has certain rights in the invention. 

BACKGROUND 

Analyzing execution traces of programs is oftentimes per- 
formed to debug and/or otherwise analyze computer pro- 
grams. Unfortunately, many computer programs can result in 
execution traces that are very long and/or complex. This 
problem is exacerbated for parametric traces, which are traces 
that contain events with parameter bindings. In parametric 
traces, the execution trace typically includes multiple trace 
slices merged together, with each trace slice corresponding to 
a parameter binding. Accordingly, it can be difficult to ana- 
lyze execution traces, particularly for parametric traces. 

SUMMARY 

This Summary is provided to introduce subject matter that 
is further described below in the Detailed Description. 
Accordingly, the Summary should not be considered to 
describe essential features nor used to limit the scope of the 
claimed subject matter. 

In accordance with one or more aspects, a program trace is 
obtained and events of the program trace are traversed. For 
each event identified in traversing the program trace, a trace 
slice of which the identified event is a part is identified based 
on one or more parameter instances in the identified event. 
For each trace slice of which the identified event is a part, the 
identified event is added to an end of a record of the trace slice. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Non-limiting and non-exhaustive embodiments are 
described with reference to the following figures, wherein 
like reference numerals refer to like parts throughout the 
various views unless otherwise specified. 

FIG. 1 illustrates an example system employing the para- 
metric trace slicing in accordance with one or more embodi- 
ments. 

FIG. 2 is a flowchart illustrating an example process for 
parametric trace slicing in accordance with one or more 
embodiments. 

FIG. 3 is a flowchart illustrating an example process for 
parametric trace slice monitoring in accordance with one or 
more embodiments. 

FIG. 4 is a flowchart illustrating an example process for 
parametric trace slice mining in accordance with one or more 
embodiments. 
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FIG. 5 is a block diagram illustrating an example comput- 
ing device in which the parametric trace slicing can be imple- 
mented in accordance with one or more embodiments. 

DETAILED DESCRIPTION 

Parametric trace slicing is discussed herein. A program 
trace is a parametric execution trace containing events with 
parameter bindings, and is traversed to identify multiple para- 
metric trace slices in the program trace. During the traversal, 
a table of parametric trace slices is generated. This table can 
be subsequently accessed to retrieve one or more parametric 
trace slices without re-traversing the program trace. These 
parametric trace slices can be used in a variety of different 
manners, such as for one or more of monitoring, mining, and 
predicting. 

FIG. 1 illustrates an example system 100 employing the 
parametric trace slicing in accordance with one or more 
embodiments. System 100 includes a direct program instru- 
mentation module 102, a predictive program instrumentation 
module 104 , a parametric trace slicing module 106 , a moni- 
toring module 108 , and a mining module 110 . Each of mod- 
ules 102 , 104 , 106 , 108 , and 110 can be implemented in 
software, firmware, and/or hardware. Additionally, each 
module 102 , 104 , 106 , 108 , llOcan be implemented by oneor 
more computing devices. Furthermore, modules 102 , 104 , 
106 , 108 , and 110 can all be implemented in the same com- 
puting device, or alternatively implemented by different com- 
puting devices. In embodiments where system 100 is imple- 
mented by multiple computing devices, the multiple 
computing devices can communicate with one another via a 
variety of different types of communications networks. For 
example, the computing devices can communicate with one 
another using a direct wired or wireless coupling of the com- 
puting device, the Internet, a local area network (LAN), a 
public telephone network, a cellular or other wireless phone 
network, combinations thereof, and so forth. 

Parametric execution traces 120 can be generated using a 
variety of different techniques, such as using direct program 
instrumentation and/or predictive program instrumentation. 
In one or more embodiments, parametric execution traces 120 
are generated by module 1 02 using direct program instrumen- 
tation. In such embodiments, parametric traces are con- 
structed in the order events occur in the actual program. 

In alternate embodiments, parametric execution traces 120 
are generated by module 104 using predictive program instru- 
mentation. In such embodiments, multiple parametric execu- 
tion traces 120 are output by module 104 , one of which 
corresponds to the actual order of observed events in a pro- 
gram. The other parametric execution traces correspond to 
possible sequences of events with respect to a partial order 
such as “happens-before” or “sliced causality”, and are rel- 
evant in multi-threaded or distributed programs. These other 
parametric execution traces are not the actual observed trace, 
although these other parametric execution traces may occur in 
different runs or executions of the program. Thus, using pre- 
dictive program instrumentation additional bugs or errors can 
be found that did not occur when the program was actually 
mn. 

Parametric trace slicing module 106 receives one or more 
execution traces 120 . Module 106 analyzes parametric execu- 
tion traces 120 and outputs one or more trace slices 122 
obtained from the parametric execution traces 120 . In one or 
more embodiments, trace slices 122 are output by system 100 
for analysis (e.g., by a program developer). In addition to (or 
alternatively in place of) system 100 outputting trace slices 
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122, trace slices 122 can be input to one or more of monitoring 
module 108 and mining module 110. 

A parametric execution trace 120 is an execution trace that 
contains events with parameter bindings. Events with param- 
eter bindings are present in programs where abstract param- 5 
eters (e.g., variable names) are bound to concrete data (e.g., 
heap obj ects) at runtime. Accordingly, a parametric execution 
trace 120 can include numerous events with numerous param- 
eter bindings. Parametric trace slicing module 106 analyzes a 
parametric execution trace 120 and obtains the trace slices 
corresponding to each instance of a parameter. Module 106 
generates a record (e.g., a table) of parametric trace slices 
while traversing trace 120, thereby avoiding any need to 
re-traverse the trace for each instance of a parameter. Module 
106 also obtains the trace slices without imposing restrictions 
on the type of parametric execution trace 120. For example, 15 
the first event for a particular property instance need not bind 
all the parameters for the property. 

Monitoring module 108 monitors parametric execution 
traces and determines whether the monitored traces comply 
with particular constraints. These constraints can be speci- 20 
fied, for example, as regular expressions identifying the for- 
mat that monitored traces are to follow. Monitoring module 
108 can operate on parametric execution traces 120 and/or 
trace slices 122. An indication of whether traces and/or trace 
slices comply with the particular constraints can be output by 2 5 
monitoring module 1 08 in a variety of different manners, such 
as by generating one or more tables and/or other records. 
These indications are output by module 108 as monitoring 
results 124. 

Mining module 110 analyzes trace slices 122 to generate 
non-parametric state-based specifications together with 
equivalent regular expressions. An indication of these speci- 
fications and/or regular expressions are output by module 1 10 
as mining results 126. Mining module 110 automatically 
detects various aspects regarding the maimer in which the 
underlying program (that was executed to generate paramet- 35 
ric execution traces 120) operates. For example, mining mod- 
ule 110 can automatically detect Application Programming 
Interface (API) patterns, usage scenarios, and so forth. 

Direct Program Instrumentation 40 

Direct program instrumentation refers to obtaining a para- 
metric execution trace corresponding to an actual execution 
of a program. Direct program instrumentation is performed 
by, for example, direct program instrumentation module 102 4S 
of FIG. 1. 

Generally, using direct program instrumentation, particu- 
lar points of interest in a program are specified. The location 
of these points of interest can be specified in different man- 
ners, such as by a user (e.g., a program developer or system 
administrator), or by another module or device. When such 50 
specified points of interest in the program are reached, they 
are reported as an event to one or more other modules in the 
system. A set of such events reported for a program are the 
parametric execution trace for the program. Direct program 
instrumentation can be performed in a variety of different 55 
conventional manners. For example, direct program instru- 
mentation can be performed using an aspect language such as 
AspectJ. Additional information regarding the AspectJ aspect 
language can be found in, for example, “An Overview of 
AspectJ”, by G. Kiczales, E. Hilsdale, J. Hugunin, M. Ker- 60 
sten, J. Palm, and W. G. Griswold, European Conference on 
Object Oriented Programming (ECOOP) ’01 (2001). 


Predictive Program Instrumentation 

Predictive program instrumentation refers to attempting to 
infer all possible execution traces in a multi-threaded or dis- 
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tributed program in which different inter-leavings of execu- 
tion of the threads or distributed pieces can result in different 
execution traces. Predictive program instrumentation is per- 
formed by, for example, predictive program instrumentation 
module 104 of FIG. 1. It should be noted that although infer- 
ring all possible execution traces is attempted, the predictive 
program instrumentation may actually infer fewer than all 
possible execution traces. 

Predictive program instrumentation begins by generating a 
direct trace of program events (e.g., using direct program 
instrumentation as discussed above). At predetermined points 
during the collection of the direct trace, a partial order of 
events is determined using control relations such as “hap- 
pens-before” or “sliced causality”. The partial order of events 
can be determined using a variety of different control rela- 
tions. Additional information regarding the “happens-before” 
control relation can be found in, for example, “Time, Clocks, 
and the Ordering of Events in Distributed Systems”, by L. 
Lamport, Communications of the ACM, 21(7):558565 
(1978). Additional information regarding the “sliced causal- 
ity” control relation can be found in, for example, “Parametric 
and Sliced Causality”, by F. Chen and G. Rosu, Computer 
Aided Verification (CAV) ’07 (2007). 

The location of these predetermined points can be specified 
by a user (e.g., a program developer or system administrator), 
or by another module or device. In one or more embodiments, 
the location of the predetermined points is determined by 
balancing precision of the partial orders (which is increased 
or improved by spacing the predetermined points further 
apart) against runtime overhead (which is decreased or 
improved by spacing the predetermined points closer 
together). 

The feasible traces with respect to these determined partial 
orders of events are generated. For example, assume a pro- 
gram generates a trace a b c, where each letter represents an 
event, and that the control relation used determines that a 
must occur before c. In this example, then, the feasible traces 
b a c and a c b can be inferred. The parametric execution traces 
generated by the predictive program instrumentation include 
these feasible traces as well as the actual traces from the direct 
trace of program events. Thus, the parametric execution trace 
includes feasible traces that were not actually part of the 
tested execution of the program. This allows errors that occur 
within a feasible trace (but do not occur in the actual tested 
execution of the program) to be identified orpredicted. Refer- 
ring to FIG. 1, this allows the monitoring performed by moni- 
toring module 108 and/or the mining performed by mining 
module 110 to be performed based on feasible traces that did 
not occur in the actual tested execution of the program. 

Parametric Trace Slicing 

Parametric trace slicing refers to obtaining from (or iden- 
tifying in) a parametric execution trace multiple trace slices 
each of which corresponds to an instance of a parameter in the 
parametric execution trace. Parametric execution traces can 
be obtained using a variety of different instrumentation tech- 
niques, such as the direct program instrumentation and/or 
predictive program instrumentation techniques discussed 
above. Parametric trace slicing is performed by, for example, 
parametric trace slicing module 106 of FIG. 1. 

In the discussions herein, e refers to a set of non-parametric 
events (also referred to as base events). An e-trace is a non- 
parametric trace when e is understood or not important. An 
e-trace is referred to as any finite sequence of events in e, also 
referred to as an element in e * . An event can be referred to as 
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e and a trace can be referred to as w, and if an event eEe 
appears in a trace wEe*, this situation is also referred to as 
e£w. 

An 6-property P, also referred to as a base or non-paramet- 
ric property, is a function P: e— »C that partitions a set of traces 5 
into categories C. In one or more embodiments, categories in 
C include “validating”, “violating”, and “don’t know” (also 
referred to as Other categories for C can alternatively be 
used, such as “matching” and “don’t care”. 

A regular expression can be used to identify an acceptable 10 
or proper format for a trace (or portion thereof). This can also 
be referred to as a constraint on the trace (or portion thereof). 
Assuming C is the set {validating, violating, don’t know}, 
and for a given regular expression E of a trace, the property 15 
P £ :e*— »C of the regular expression E is defined as follows: 
P £ (w)=validating if and only if w is in the language of E, 
P^lwj^iolating if and only if there is no w'Ee* such that w 
w' is in the language of E, and P £ (w)=don’t know otherwise. 

These preceding definitions can be extended to the para- 20 
metric case where events carry concrete data instantiating 
abstract parameters as follows. For example, assume an event 
Acquire and an event Release are parametric in their resource 
(a resource to be acquired and released). Assume r is the name 
of the generic resource parameter, and that ^ and r 2 are two 25 
concrete resources. Following this assumption, parametric 

acquire/release events have the form Acquire^ rl-*^) , 

Release( rH» r 2 ) , and so forth. It should be noted that not all 
events need carry instances for all parameters. For example, 30 
Begin and End parametric events (signifying the beginning 
and ending, respectively, of a procedure), have the form Begin 

{ 1) and End( 1) , where _L refers to the partial map undefined 
everywhere and instantiates no parameter. The sets of total/ 
partial functions from A to B are also referred to as [A^B]/ 

[ A-. B] . 

A set of parameters is referred to as X, and a set of corre- 
sponding parameter values is referred to as V. A set of base 
events is referred to as e as discussed above, and e( X) is a set 40 
of corresponding parametric events e( 0) where e is a base 
event in e and 0 is a partial function [X-iV], A parametric 

trace is a trace with events in X-i , also referred to as a word 
in eh->X) *. 

In the discussions herein, the parameter values set V is 45 
implicit to simplify writing. For example, a parametric trace 

can be: Begin(T) Acquire^) Acquire^ 0 2 ) Acquire(0j) 
Release(0 1 ) End(T) Begin) T) Acquire( 0 2 ) Release(0 2 ) 

End( _L) , where 0 X maps r to r l and 0 2 maps r to r 2 . Addition- 50 
ally, in the discussions herein just the parameter values are 
listed when writing parameter instance, such as ( rj-i instead 

of { rl — ¥ r : ) , x I r 2 instead of x I rl— » r 2 , and so forth. Using this 
notation, the previous example parametric trace can be writ- 55 
ten as: Begin( ) Acquire(r) Acquire(r 2 ) Acquire^,} 

Release^} End( ) Begin( ) Acquire(r 2 ) Release(r 2 ) End 
( ) . This example parametric trace thus involves two 
resources (^ and r 2 ), and includes two trace slices (one for 60 
each of the two resources). The Begin and End events in the 
parametric trace belong to both trace slices. The trace slice 
corresponding to 0 X is: Begin Acquire Acquire Release End 
Begin End. The trace slice corresponding to 0 2 is: Begin 
Acquire End Begin Acquire Release End. 65 

Partial functions 0 in [X-i V] are referred to as parameter 
instances. The 0 and 0'E[A-i B] are referred to as being com- 
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patible if for any xEDom(0)nDom(0') where 0(x)=0'(x). 
Compatible instances 0 and 0' can be combined, written as 
0^,0', as follows: 

{ ' 9(x ) when 9(x) is defined 
9'(x ) when 9' (x) is defined 
undefined otherwise 

The 0 l 0' is also referred to as the least upper bound (lub) 
of 0 and 0'. The 0' is less informative than 0, or 0 is more 
informative than 0', also written as 0’— . 0 if and only if for any 
xEX, if 0'(x) is defined then 0(x) is also defined and 0'(x)=0 
(x). For example, { ) is compatible with ( r x ) and with ( r 2 ) , 
but(rj) and(r 2 ) are not compatible. Additionally, ()-(r 1 ) 
and ( ) E ( r 2 ) . 

Given a parametric trace xEe( X) * and 0 in [X-i V], then 

the 0-trace slice x I 0Ee* is the non-parametric trace defined 
as: 

e ; =e, where € is the empty trace/word, and 
(xeh-> 0) ) ! 0=(x-i 0)e when 0' g 0, and 
(xel->0l )l 0=xl 0 when©' I 0. 

The trace slicex) 0 first filters out the parametric events that 
are not relevant for the instance 0. The parametric events that 
are not relevant for the instance 0 are the parametric events 
that contain instances of parameters that 0 does not care about 
(e.g., instances of parameters not included in 0). For the 

remaining events relevant to 0, the trace slice x I 0 forgets or 
drops the parameters so that the trace can be checked against 
base, non-parametric properties. It should be noted obtaining 
such trace slices is different from extracting traces from 
executions and abstracting traces from executions. Extracting 
traces refers to determining the events to include in the trace, 
as well as parameter instances carried by events. Abstracting 
traces refers to dispatching each event in the given trace to 
corresponding trace slices according to the event’s parameter 
instance. 

A set of parameters together with their corresponding 
parameter values V is referred to as X, and P:e*— »C refers to 
a non-parametric property as discussed above. The paramet- 
ric property AX-P is defined as the property (over traces 
e(X) * and categories [[X-i V]-»C]): 

AX-P:e{ X) *^>[[X-,]^>C] 

which is referred to as (AX-P)(x)(0)=P(xl 0) for any xEeH* 
X) * and any 0E[X-i V]. If X={x 1 , . . . , x„}, then (A{x 1; . . . , 
x„} P) can be written as Ax 1; . . . ,x„-P. Additionally, P^, refers 
to a pattern or formula <} in some particular trace specification 
formalism, then AX-P^ is written as AX-(|>. 

Parametric properties AX-P over base properties P:e*— *C 
are thus properties taking traces in el— » X) * to categories [[X 
-i V]— »C], in other words to function domains from parameter 
instances to base property categories. AX-P is defined as if 
many instances of P are observed at the same time on the 
parametric trace, one property instance for each parameter 
instance, and each property instance concerned with its 
events only (dropping the unrelated events). 

Generally, to slice parametric traces, a parametric slicing 
process is used that takes a parametric execution trace incre- 
mentally and builds a partial function of finite domain as a 
lookup table for all slices of the parametric trace. The param- 
eter instances are the index used to lookup slices in the lookup 
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table. The various parametric trace slices in the parametric 
trace are identified in this lookup table. A trace slice is com- 
puted for all combinations of parameter instances observed in 
parametric trace events in the trace. In order to obtain a 
particular slice for a particular set of functions instantiating a 
particular set of parameter values, a most informative set of 
parameter instances is calculated. This most infonnative set 
of parameter instances refers to all the parameter instances 
used in the particular slice. The lookup table is then accessed 
to identify the parametric trace slice identified by the most 
informative set of parameters. Thus, the parametric trace can 
be processed or traversed one time as the lookup table is being 
generated. Appropriate data structures are maintained as the 
lookup table so that parametric trace slices can be subse- 
quently retrieved for any parameter instance without process- 
ing or traversing the parametric trace again. 

FIG. 2 is a flowchart illustrating an example process 200 
for parametric trace slicing in accordance with one or more 
embodiments. Process 200 can be implemented in software, 
firmware, hardware, or combinations thereof. Process 200 is 
carried out by, for example, a parametric trace slicing module 
106 of FIG. 1. Process 200 is shown as a set of acts and is not 
limited to the order shown for perfonning the operations of 
the various acts. Process 200 is an example process for para- 
metric trace slicing; additional discussions of parametric 
trace slicing are included herein with reference to different 
figures. 

In process 200, a program trace is obtained (act 202). The 
program trace can be obtained from a variety of different 
sources in a variety of different conventional manners. The 
program trace can be a trace of a previously run program, or 
alternatively an on-going trace of a program currently run- 
ning 

The trace is traversed from the first event in the trace to the 
last event in the trace (act 204). Each event in the trace is 
analyzed as the trace is traversed. Alternatively, the program 
trace can be traversed in different orders other than from the 
first event to the last event. 

The first event in the trace is identified during the traversal 
(act 206). This first event can be a parametric event or a 
non-parametric event. 

Based on the parameter instances in the identified event, 
each trace slice of which the identified event is a part is 
identified (act 208). An event is part of a trace slice if the 
parameter instance of the event is less infonnative than (-> ) 
the parameter instance of the trace slice. If the event includes 
no parameter instances, then the event is a part of all trace 
slices. A record of each different trace slice identified in the 
trace is maintained. These different trace slices correspond to 
different possible combinations of parameter instances 
observed while traversing the trace. A record of each possible 
trace slice resulting from each possible combination of 
parameter instances observed in the trace can be maintained 
regardless of whether the particular combination of param- 
eter instances is actually observed in the trace. Alternatively, 
a record of each possible trace slice resulting from the com- 
binations of parameter instances actually observed in the 
trace can be maintained. 

Hie identified event is added to the end of the trace slice 
record for each trace slice of which the identified event is a 
part (act 210). For each trace slice identified in act 208, the 
identified event is added to the end of the record of that trace 
slice. It should be noted that the identified event can be added 
with or without its parameter instances. 
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A check is then made as to whether the identified event is 
the last event in the trace (act 212). If the identified event is the 
last event in the trace, then process 200 is finished for the 
obtained trace (act 214). 

5 However, if the identified event is not the last event in the 
trace, then the next event in the trace is identified during the 
traversal (act 216). Process 200 then returns to act 208 to 
identify, based on the parameter instances in the identified 
event, each trace slice of which the identified event is a part. 
10 Process 200 illustrates an example process for parametric 
trace slicing. Example pseudo code for an algorithm perform- 
ing parametric trace slicing is included in Table I below. The 
algorithm A{ X) in Table I takes a parametric trace xEel-» 
15 X) * incrementally and builds a partial function TE[[X 
-iV]— »€*] of finite domain as a quick lookup table for all 
slices of x. Given sets of partial functions 0, 0' <= [X-i V] , u 0 
is the least informative partial function 0E[X-i V] such that 
for any 0'E0, 0'— 1 0; max 0 is the most infonnative 0E0; 0 
2° L 0'={0 L 0'|0e0, 0'E0' such that 0^0' exists} and 
(0] e ={0'l0'E0 and 0'— 1 0}. It should be noted that ^0 and 
max 0 may not exist. The algorithm Ah-» X) in Table I takes 
an input of a parametric trace xEel-> X) * , and outputs a map 
or lookup table TE[[X-> V]-»e*] and a set 0 <= [X-i V]. 


TABLE I 


1 

T 1 ; T(±) ^ e; 0 ^ {±} 

2 

for each e(0 in order in x do 

3 

: for each 0'G {0} ^ 0 do 

4 

: : T (0‘) *- T(max(0']© )e 

5 

: end for 

6 

: © *- { _L,0} L0 

7 

end for 


35 The algorithm Al-> X) in Table I operates on input x, also 
written as AH X) (x), traverses x from its first event to its last 
event and, for each encountered event el-» 0) , updates both its 
data stmctures T and 0. After processing each event, the 
40 relationship between T and 0 is that 0 is a domain of T. 

In the algorithm Al— » X) in Table I, at line 1 the data struc- 
tures T and 0 are initialized. T is undefined everywhere (_L) 
except for the undefined everywhere function _L, where 
T(T)=€. 0 is initialized to the set { _L} . The code at lines 3 to 
45 6, inside the outer loop (at lines 2 to 7) is triggered when a new 
event is received. When a new event el— » 0) is received, T is 
updated as follows. For each 0'[X-i V] that can be obtained by 
combining 0 with the compatible partial functions in the 
domain of the current T, update T(0') by adding the non- 
50 parametric event e to the end of the slice corresponding to the 
largest (the most knowledgeable) entry in the current table T 
that is less infonnative or as informative as 0'. Then, at line 6, 
0 is extended. 

As an example, consider a sample parametric trace with 
55 parametric events in {a, b, c}. The sample parametric trace 

x=e 1 l-»a 1 ) e 2 l-»a 2 ) e 3 l-»b 1 ) e 4 l-»a 2 b 1 ) ejl-^aj) e 6 ( ) e 7 
HAbj). The following example records illustrate how the 
algorithm Al-> X) works on the sample parametric trace x. 
An entry of the form l-> 0) :w in a record corresponding to a 
60 current parametric event el-A0) means that T(0)=w after pro- 
cessing all the parametric events up to and including the 
current parametric event; T is undefined on any other partial 
function. The 0 corresponding to a record is the union of all 
the 0’s that appear in pairs l-> 0) :w in that record. It should be 
65 noted that as each parametric event el-A 0) is processed, the 
non-parametric event e is added at most once to the record of 
each slice. Tables II-VIII below illustrate the contents of each 



US 8,719,796 B2 


10 

TABLE VIII 


9 


record for a trace slice after the event identified in each table 
has been analyzed during traversal of the sample trace. 

TABLE II 

e,(a) 

<>:e 

(a) : e, 


TABLE III 

():e 
(a): e, 
W:e 2 


TABLE IV 
e 3 (b) 

<>:e 

(a) : e, 

W : e 2 

(b) : e 3 

(ajb^: eje 3 

(a 2 b): e 2 e 3 


TABLE V 

e 4 (a 2 b) 

<>:e 

W : e, 

<a):e 2 
09 : e 3 
(a,b,) : e,e 3 
(a 2 b 1 ) : e 2 e 3 e 4 


TABLE VI 

e 5 W 

<>:€ 

(a,) : e,e 5 
09 : e 2 
<bi> : e 3 
{a,b) : eje^ 
0M9 : e 2 e 3 e 4 

TABLE VII 
e 6 () 

<):e 6 

<a 1 >:e 1 e 5 e 6 
(a 2 ):e 2 e 6 
( b, ) : e 3 e 6 

(a 2 bj>:e 2 e 3 e 4 e 6 


e 7 ( b,) 

5 ()- e 6 

(nj-.e&eg 
(a 2 ):e 2 e 6 
( bj ) : e 3 ege 7 
{ ajbj) : e 1 e 3 e 5 e 6 e 7 
( a 2 b,>: e 2 e 3 e 4 e 6 e 7 
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Parametric Trace Slice Monitoring 

Trace slice monitoring refers to analyzing the parametric 
trace slices to verify parametric properties in the execution 
trace. This monitoring can be used, for example, to assist in 
the identification of errors or problems in the underlying 
program (the program whose execution results in the execu- 
., (| tion trace). Monitoring of the parametric trace slices is per- 
formed by a monitoring module, such as module 108 of FIG. 
1 . The monitoring of the parametric trace slices can be per- 
formed as the underlying program is running, or alternatively 
after the underlying program lias run. 

25 For parametric trace slice monitoring, a set of monitors M 
and a set of parametric monitors AX-M are defined. Paramet- 
ric monitors refer to monitors for parametric events and have 
parameter instance-indexed states and output categories. A 
parametric monitor AX-M is a monitor for the property AX-P, 
30 with P being the property monitored by M. 

A monitor M is a tuple (S, 6, C, t, ct: S xe-»S, y:S-»C), 
where S refers to a set of states, 6 refers to a set of input events, 
C refers to a set of output categories, iGS is the initial state, ct 
is the transition function, and y is the output function. The 
35 transition function is extended to CT:Sxe*-»S in the standard 
way: ct(s.6)=s and CT(s,we)=CT(CT(s,w),e) for any s£S, eEe, and 
wEe*. It should be noted, however, that implementations of 
monitors need not generate all the state space ahead of time, 
but rather can generate the state space as needed. It should 
40 also be noted that, although a finite number of states is 
reached during any given (finite) execution trace, in general 
there is no bound on the number of states. 

A monitor M=(S, 6, C, i, ct, y) is a monitor for property 
P:€*— >C if and only if y(ct(i,w))=P(w) for each wEe*. Each 
45 monitor M defines the property P M :e*^>C with P^(w )=y(ct 
(i.,w)). Each such monitor M is referred to as a monitor for P M . 
Two monitors M and M' are equivalent, referred to as M=M' 
and only ifP^P^,. 

Given parameters X with corresponding values V, and 
50 monitor M=(S, €, C, i, cr:Sxe— »S, y: S— »C), the parametric 
monitor AX-M is the monitor 
([[X-, V]^S], el-»X) ,[[X-, V]^C], X6 -l,AX-ct,AX-y) 
with AX-ct: [[X-, V]^S]xel-AX) ^[[X-, V]^SJ 
and AX-y:[[X-i V]— »S]— »[[X-i V]— »C] defined as, for any 
55 6E[[X-i V]— »S] and any 0, 0'E[X-i V], the following: 

(AX-CT)(6el-> 0’) )(0)=cr(8(0),e) if 0’-, 0, and 

(AX-ct)(8, el-> 0') )(0)=8(0) if 0'iz0, and 

(AX-y)(8) (0)=y(8(0)). 

In other words, a state 8 of parametric monitor AX-M main- 
60 tains a state 8(0) of M for each parameter instance 0, takes 
parametric events as input, and outputs categories indexed by 
parameter instances (one output category of M per parameter 
instance). 

Generally, to monitor parametric trace slices, a monitoring 
65 process is used that takes parametric trace slices and builds 
records of states of monitor instances, and also builds records 
indicating violation or validation of a property. Similar to the 
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parametric slicing process discussed above, the parametric 
trace slices can be processed or traversed one time as the 
records are generated. 

FIG. 3 is a flowchart illustrating an example process 300 
for parametric trace slice monitoring in accordance with one 5 
or more embodiments. Process 300 can be implemented in 
software, firmware, hardware, or combinations thereof. Pro- 
cess 300 is carried out by, for example, a monitoring module 
108 of FIG. 1. Process 300 is shown as a set of acts and is not 
limited to the order shown for performing the operations of to 
the various acts. Process 300 is an example process for para- 
metric trace slice monitoring; additional discussions of para- 
metric trace slice monitoring are included herein with refer- 
ence to different figures. 

In process 300, a program trace is obtained (act 302). The 15 
program trace can be obtained from a variety of different 
sources in a variety of different conventional manners. The 
program trace can be a trace of a previously run program, or 
alternatively an on-going trace of a program currently run- 
ning Additionally, the program trace can be a parametric trace 20 
slice (e.g., generated by slicing module 106 of FIG. 1) rather 
than an entire program trace (in which case the parameter 
instance of every event will be _l_). 

The trace is traversed from the first event in the trace to the 
last event in the trace (act 304). Each event in the trace is 25 
analyzed as the trace is traversed. Alternatively, the trace can 
be traversed in different orders other than from the first event 
to the last event. 

The first event in the trace is identified during the traversal 
(act 306). This first event can be a parametric event or a 30 
non-parametric event. 

Based on the parameter instances in the identified event, 
the monitor instance corresponding to the identified event is 
identified (act 308). An event is part of a trace slice if the 
parameter instance of the event is less informative than (-, ) 35 
the parameter instance of the trace slice. A record of each 
different monitor instance identified in the trace is main- 
tained. These different monitor instances correspond to dif- 
ferent possible combinations of parameter instances observed 
while traversing the trace. A record of each possible monitor 40 
instance resulting from each possible combination of param- 
eter instances observed in the trace can be maintained regard- 
less of whether the particular combination of parameter 
instances is actually observed in the trace. Alternatively, a 
record of each possible monitor instance resulting from the 45 
combinations of parameter instances actually observed in the 
trace can be maintained. 

The identified event is added to the monitor instance record 
for each monitor instance corresponding to the identified 
event (act 310). For each monitor instance identified in act 50 
308, the identified event is added to the record of that monitor 
instance. The identified event can be added to the end of the 
record, or alternatively elsewhere in the record. It should be 
noted that the identified event can be added with or without its 
parameter instances. 55 

An output corresponding to the identified monitor instance 
is also determined (act 312). The output corresponding to the 
identified monitor instance, based on the events added to the 
identified monitor instance thus far, is calculated. This output 
comprises determining, for example, whether the trace slice 60 
corresponding to that monitor instance is validating, violat- 
ing, or don’t know. In other words, whether the trace slice 
corresponding to that monitor instance complies with the 
appropriate constraints. This determination is made, for 
example, based on a regular expression of a trace as discussed 65 
above. For example, if a regular expression indicates that an 
Acquire event is to precede a Release event, then it can be 
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determined that the output corresponding to the identified 
monitor instance is validating if an Acquire event precedes the 
Release event in a trace slice (and any other regular expres- 
sions for the trace slice are satisfied), but violating if an 
Acquire event does not precede the Release event. 

An indication of the determined output is added to a record 
corresponding to the identified monitor instance (act 312). 
For example, an indication of validating, violating, or don’t 
know can be added to the record. Alternatively, indications of 
validating or violating may be added to the record, but indi- 
cations of don’t know are not added. 

A check is then made as to whether the identified event is 
the last event in the trace (act 3 1 6 ). If the identified event is the 
last event in the trace, then process 300 is finished for the 
obtained trace (act 318). 

However, if the identified event is not the last event in the 
trace, then the next event in the trace is identified during the 
traversal (act 320). Process 300 then returns to act 308 to 
identify, based on the parameter instances in the identified 
event, the monitor instance corresponding to the identified 
event. 

Process 300 illustrates an example process for parametric 
trace slice monitoring. Example pseudo code for an algorithm 
performing parametric trace slice monitoring is included in 
Table IX below. The algorithm Bl->X) in Table IX encodes 
functions [[X-iV]-.S] as tables with entries indexed by 
parameters instances in [X-i V] and with content states in S. 
The algorithm Bl-* X) in Table IX uses a data structure A that 
is a record of monitor instance states, and a data structure T 
that is a record of indications of whether the output corre- 
sponding to the monitor instance violates or validates the 
property (e.g., whether one or more regular expressions for 
the trace or trace slice is satisfied). In the algorithm Bl-* X) in 
Table IX, A is mapped to [[X-. V]-iS], and E is mapped to [[X 
V| C|. 


TABLE IX 


1 

A ^1; A(_L) i; 0 {1} 

2 

for each e( 0 ) in order in x do 

3 

: for each 0' G {0}^0 do 

4 

: : A (0') a(A(max(0'] 0 ),e) 

5 

: : r (0') y(A(0’)) 

6 

: end for 

7 

: 0 «- {1,0} L0 

8 

end for 


The algorithm Bl-*X) in Table IX is similar to the algo- 
rithm Al-> X) for which pseudo code is included in Table I 
discussed above. The algorithm Bl-* X ) in Table IX operates 
on input i, traverses i from its first event to its last event and, 
for each encountered event el-*0), updates both its data 
structures A, T, and 0. 

In the algorithm Bl-»X) in Table IX, at line 1 the data 
structure A is initialized as undefined everywhere (X) except 
for the undefined everywhere function T, A(X) is initialized to 
i, and 0 is initialed to the set {X}. The code at lines 3 to 7, 
inside the outer loop (at lines 2 to 8) is triggered when a new 
event is received. When a new event el-* 0) is received, at line 
4 the state of the monitor instance corresponding to 0' is 
calculated and stored in the record A corresponding to 0' by 
sending e to the corresponding monitor instance. Addition- 
ally, at line 5 a determination is made whether the output 
corresponding to the monitor instance violates or validates 
the property, and an indication of the determination is stored 
in the data structure T. Then, at line 7, 0 is extended. 

In the implementation of algorithm Bl-* X) in Table IX, a 
search is made (at line 3) for all parameter instances in 0 that 
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are compatible with 0. Alternatively, an auxiliary data struc- 
ture can be used to reduce the amount searching that is per- 
formed, so that a search for all parameter instances in 0 that 
are compatible with 0 need not be performed. The auxiliary 
data structure maps each parameter instance 0 into the finite 5 
set of parameter instances encountered in A thus far that are 
more informative than 0. For example, the auxiliary data 
structure can be referred to as U, and is defined as 
U(0)={0'I0'S Dom(A) and 0 r 0'}. Accordingly, the amount 
of searching that is performed is reduced as only the param- to 
eter instances encountered thus far that are more informative 
than the current parameter instance need be considered. 

Example pseudo code for another algorithm performing 
parametric trace slice monitoring is included in Table X 
below. The algorithm Cl—»X) in Table X is similar to the 15 
algorithm Bl-A X) in Table IX, except that the search at line 3 
of algorithm Bl-AX) in Table IX is replaced so that a reduced 
amount of searching is performed. The algorithm Cl-A X) in 
Table X uses the auxiliary data structure U discussed above. 

20 

TABLE X 

Initialize U(0) *- { } for any 0 E [X-, V] 

Initialize A(±) ■*- i 
function main (el 0)) 

1 if A(0) undefined then -5 

2 : for each Q max r 9 On reversed topological order (larger to smaller)) do 

3 : : if MQ max ) defined then 

4 : : : go to line 7 

5 : : end if 

6 : end for 

7 : defineTo (Q,Q max ) 30 

8 : for each Q max d 0 (in reversed topological order ( larger to smaller) ) do 

9 : : for each 6 comp E U(Q max ) compatible with 0 do 

10 : : : if A(Q comp l0) undefined then 

11 : : : : defineTo(0 OT ^0,0^) 

12 : : : end if 

13 : : end for 35 

14 : end for 

15 end if 

16 for each 6'G {0} w U(0) do 

17 : A (0') «- a(A(0'), e) 

18 : T (0') «- y(A(0')) 

19 end for 

function defineTo (0,0’) 

1 A(0) A(0') 

2 for each 0" r 0 do 

3 : U(0") *- U(0") w { 0 } 

4 end for 


The algorithm Cl-AX) in Table X using mappings for A 
and T as discussed above with reference to algorithm Bl— » 

X) in Table IX, and in addition U is mapped to [X-. 

([[X-iV]]), where P/S) is the finite power set of set S. The 
algorithm Cl-A X) in Table X is composed of two functions: 50 
“main” and “defineTo”. The “defineTo” function takes two 
parameter instances, 0 and 0', and adds a new entry corre- 
sponding to 0 into A and U. More specifically, the “defineTo” 
function sets A(0) to A(0') and adds 0 into the set U(0") for 
each 0" c 0'. 55 

The “main” function differentiates two cases when a new 
event el-A e) is received and processed. The first case is that A 
is already defined on 0, in other words 0G0 at the beginning 
of the outer loop (lines 2-8) of the algorithm Bl-A X) in Table 
IX. In this first case, {0}^0={0'l0'e0 and 0-.0'}<=0, so 60 
lines 3 to 6 of the algorithm Bi-aX) in Table IX become the 
lines 16 to 19 of the algorithm Cl-AX) in Table X. 

In the second case of the “main” function, when A is not 
already defined on 0, two steps are taken to process e. The first 
step searches for new parameter instances introduced by 65 
{0}^0 and adds entries for these new parameter instances 
into A (at lines 2 to 15). More specifically, at lines 2 to 7 an 
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entry is added to A for 0. A search for all parameter instances 
Q co that are compatible with 0, making use of U (at lines 8 
and 9), and for each such B comp an appropriate entry is added 
to A for its least upper bound with 0, and U is updated 
accordingly (at lines 10 to 12). Thus, A is defined on the new 
parameter instances introduced by {0} l© after the first step. 
In the second step, the related monitor states and outputs are 
updated in a similar way as in the first case (at lines 16 to 1 9). 

Example pseudo code for another algorithm performing 
parametric trace slice monitoring is included in Table XI 
below, and is referred to as algorithm C + l-A X) . Algorithm C + 
l-A X) in Table XI is similar to algorithm Cl-A X) in Table X, 
but extends algorithm Cl-A X) in Table X to include creation 
events. Creation events refer to events that lead to creation of 
new monitor states. The algorithm Cl-A X) in Table X can be 
viewed as a special case of the algorithm C + l-A X) in Table XI 
in which all events are creation events. The creation events 
typically occur as a result of a request (e.g., a user request or 
a request from another component or module) to begin moni- 
toring — each new event encountered after the request to begin 
monitoring is a creation event. The algorithm C + I-AX) in 
Table XI uses the data structure A that is a record of monitor 
instance states, the data structure T that is a record of indica- 
tions of whether the output corresponding to the monitor 
instance violates or validates the property, and the auxiliary 
data structure U discussed above. 

The algorithm C + l-A X) in Table XI includes an additional 
function “defineNew” that takes a parameter instance 0 and 
adds a new entry corresponding to 0 into A and U. 

TABLE XI 

Initialize U(0) ■*- { } for any 0 E [X-, V] 

function main (e{ 0)) 

1 if A(0) undefined then 

2 : for each Q max r® (in reversed topological order (larger to smaller)) do 

3 : : if A(0 ma;( ) defined then 

4 : : : go to line 7 

5 : : end if 

6 : end for 

7 : if A(0 max ) defined then defineTo (0,0 max ) 

8 : else if e is a creation event then defineNew(0) 

9 end if 

10 : for each 0„ jax( -6 (in reversed topological order (larger to smaller)) do 

11 : : for each Q comp E 13(0^^) compatible with 0 do 

12 : : : if A(Q comp l 0) undefined then 

13 : : : : defmeTofe^^e.G^^) 

14 : : : end if 

15:: end for 

1 6 : end for 

17 end if 

18 for each 0'E {0} w U(0) do 

19 : A (0‘) *- a(A(0'), e) 

20 :T( 0 1 )-V(A(0')) 

21 end for 

function defineTo (0,0') 

1 A(0) *- A(0') 

2 for each ©"q© do 

3 : U(0") *- U(0") w {0} 

4 end for 

function defineNew(0) 

1 A(0) *- i 

2 for each 0" r 0 do 

3 : U(0") *- U(0") w {6} 

4 end for 


Parametric Trace Slice Mining 

Parametric trace slice mining refers to generating specifi- 
cations for the underlying program based on the parametric 
trace slices obtained from an execution trace. The specifica- 
tions identify various aspects regarding the manner in which 
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the underlying program, such as API patterns, usage sce- 
narios, and so forth. In addition to generating the specifica- 
tions, regular expressions equivalent to the specifications can 
also be generated. 

FIG. 4 is a flowchart illustrating an example process 400 5 
for parametric trace slice mining in accordance with one or 
more embodiments. Process 400 can be implemented in soft- 
ware, firmware, hardware, or combinations thereof. Process 
400 is carried out by, for example, a mining module 110 of 
FIG. 1 . Process 400 is shown as a set of acts and is not limited to 
to the order shown for performing the operations of the vari- 
ous acts. Process 400 is an example process for parametric 
trace slice mining; additional discussions of parametric trace 
slice mining are included herein with reference to different 
figures. 15 

In process 400 , trace slices are obtained (act 402 ). These 
trace slices are parametric trace slices as discussed above. It 
should be noted that although these trace slices are referred to 
as parametric trace slices, in one or more embodiments they 
do not include parameters. As discussed above, events are 20 
added to trace slices during the parametric trace slicing pro- 
cess, but these different slices correspond to particular com- 
binations of parameters . Thus, the parameters for these events 
need not recorded in the different slices as the events are 
associated with particular combinations of parameters by 25 
virtue of their being included in a particular trace slice. 

Deterministic finite automata are produced based on the 
obtained trace slices (act 404 ). A deterministic finite automa- 
ton (DFA) is a finite state machine in which for each pair of 
state and input, there is a single transition to a next state. 30 
These deterministic finite automata are generated using a 
probabilistic finite state automata (PFSA) learner. 

Refined deterministic automata are produced based on the 
use trace slices (act 406 ). Generally, the refined deterministic 
finite automata refines the deterministic finite automata pro- 35 
duced in act 404 by expanding the deterministic finite 
automata produced in act 404 to split each state according to 
its incoming edges (e.g., one state per incoming edge). The 
expanded deterministic finite automata is then traversed using 
the obtained trace slices and edges in the expanded determin- 40 
istic finite automata that are not used in any of the obtained 
trace slices are removed. The resulting deterministic finite 
automata is compressed by merging states having the same 
outgoing transitions and removing those states have no 
incoming transitions to produce the refined deterministic 45 
finite automata. 

Equivalent regular patterns are generated from the refined 
deterministic finite automata (act 408 ). These regular patterns 
are generated using a regular pattern generator that generates 
equivalent regular patterns from finite state machines. 50 

The regular patterns generated in act 408 and the refined 
deterministic finite automata produced in act 406 are output 
(act 410). One or more deterministic finite automata are gen- 
erated for each trace slice obtained in act 402 and output in act 
410 as the specification for the trace slice. Alternatively, both 55 
the regular patterns and refined deterministic finite automata 
are not output in act 410 (e.g., only one of the regular patterns 
and refined deterministic finite automata may be output). 

The following describes an example implementation of 
parametric trace slice mining. The trace slices are input to a 60 
probabilistic finite state automata learner, the output 
automata are input to an automata refiner. The automata 
refiner refines the automata, generating the finite state 
machines that are the specifications for the trace slices. These 
finite state machines are also input to a regular pattern gen- 65 
erator, which generates equivalent regular patterns from the 
finite state machines. 
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The probabilistic finite state automata learner infers a finite 
state machine (automaton) from a set of strings, which are the 
trace slices discussed above. The inferred state machine 
accepts at least the input trace slices and may allow more as 
oftentimes the probabilistic finite state automata learner gen- 
eralizes during its learning process. A variety of different 
well-known probabilistic finite state automata learners can be 
used with the parametric trace slice mining discussed herein. 
In one or more embodiments, the probabilistic finite state 
automata learner is the well-known sk-string algorithm. 
Additional information regarding the sk-string algorithm can 
be found in, for example, “The sk-strings method for inferring 
pfsa”, by A. V. Raman and J. D. Patrick, International Con- 
ference on Machine Learning (ICML) ’97 (1997). 

Generally, the sk-string PFSA learner first constructs a 
prefix tree, which is essentially a finite state automaton that 
accepts precisely the input set of strings. Each arc of the prefix 
tree is labeled with a frequency that represents how many 
times the arc was traversed during the creation of the tree. The 
sk-string algorithm is then used to merge states in the prefix 
tree to build a more compact and more general nondetermin- 
istic finite automaton. 

State merging is based on a concept referred to as “sk- 
equivalence”. In sk-equivalence, 2 refers to the set of words 
used in the strings, Q refers to the set of states in the prefix 
tree. 8: Qx2*-»2 e refers to the transition function, and F^ 
refers to the set of final states. The set of k-strings of state q is 
then defined as the set {zlzE2*,lzl=kA8(q,z)<=Qv lzl<k 
a 8(q,z PlF^^I })}. Each k-string has a probability associated 
with it that is the product of the probabilities of the arcs 
traversed in generating the string. Two states are considered 
mergeable if the sets consisting of the top s percent of their 
distribution of k-string are the same (that is, sk-equivalence). 
This is computed as follows: the k-strings of a state are 
arranged in decreasing order of their probabilities. The top n 
strings, whose probabilities add up to s percent or more with 
n being as small as possible, are retained and the remaining 
strings (those having lower probabilities) are ignored. Two 
states are sk-equivalent if the sets of the top n strings of both 
are the same. The process of merging states is repeated until 
no more states are sk-equivalent. This way, the algorithm 
infers a nondetermini Stic finite automaton accepting a super- 
set of the input strings. This nondeterministic finite automa- 
ton is then converted into a deterministic finite automaton. 

Thus, the probabilistic finite state automata learner outputs 
deterministic finite automata, each automaton having nodes 
that represent the involved components and edges are labeled 
with events. 

The deterministic finite automata output by the probabilis- 
tic finite state automata learner can be over-generalized. To 
compensate for such over-generalization, the automata 
refiner refines the deterministic finite automata output by the 
probabilistic finite state automata learner using the trace 
slices. 

Example pseudo code for an algorithm performing para- 
metric trace slice mining is included in Table XII below, and 
is referred to as algorithm R. An automaton refers to a tuple 
(S, €, i, 8, F), where S refers to a set of states, € refers to a set 
of events, iES is the initial state, 8:[Sxe-iS] is the transition 
function, and FES is the set of final states. Algorithm R 
includes a function “main” and a function “expand”. The 
“main” function of algorithm R takes as an input an automa- 
ton A=(S, 6, i, 8:[Sxe-iS], F) and a set of trace slices T<=€*, 
and outputs an automaton A r . The “main” function of algo- 
rithm R uses local values of automaton A'=(S', 6, i', 8', F'), 
state s, s', and transition function 8,.. The “expand” fimction of 
algorithm R takes as an input an automaton A=(S, e, i, 8, F) 
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and outputs an automaton A'=(S', e, i', 8', F'). The “expand” 
function of algorithm R is initialized by setting S' to { }, 
setting F' to { }, and setting 8' to _L. The “expand” function of 
algorithm R also use local values of integer n, set of states D, 
and map fS:S-»2 s '. 5 


TABLE XII 


Function main ( ) 

1 A 1 *- Expand(A) 

2 5 r -e- ± 

3 for each x £ T do 

4 : s i’ 

5 : for each e E x do 

6 : : s’ *- s 

7 : : s *- 6’(s,e) 

8 : : 6 r (s’,e) *- s 

9 : : if 6 r =6’ then 

10 ::: go to line 14 

11 : : end if 

12 : end for 

13 end for 

14 A’ «- (S', e, i’, 6 r , F) 

15 A r *- MergeldenticalStates(A') 
Function Expand 

1 for each s E S do 

2 : n *- CountIncomingEdges(s v A) 

3 : if s=i then 

4 : :n*~ n+1 

5 : end if 

6 : D *- GetFreshStates(n) 

7 : S' D S' 

8 : 0(s) «- D 

9 end for 

10 foreachsESdo 


11 

for each s'*E S such that 6(s',e)=s for some e do 

12 

: s" *- PickOneWithNoIncomingEdge(P(s),6') 

13 

: for each s’” E p(s') do 

14 

: : 6'(s"’,e)=s" 

15 

: end for 

16 

end for 

17 

if s E F then 

18 

: F' F’w fts) 

19 

end if 

20 

f s=I then 

21 

: i' PickOneWithNoIncomingEdge(p(s),6') 

22 

end if 

23 end for 

24 return A' 
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In algorithm R, the input automaton is expanded using the 
“expand” function, which splits each state according to its 
incoming edges. The incoming edges are counted as follows: 45 
if 8(s, e)=s' for some s*s', then e represents an incoming edge 
to s'. Additionally, it is assumed that the initial state has a 
default incoming edge (at lines 3 to 5 in the “expand” func- 
tion). If state s has n incoming edges then n new states are 
generated for the new automaton and the mapping from s to 50 
the corresponding set of newly created states is kept in (I (at 
lines 6 to 8 in the “expand” function). The “expand” function 
then builds transitions in the new automaton (at lines 1 0 to 23 ) 
as follows. If 8(s', e)=s is a transition in the input automaton 
and s*s' then a state s" from (3(s) with no incoming edges yet 55 
is chosen and transitions are added from every state in (I(s') to 
s". Ifs is a final state then all states in |I(s) are also final; if s is 
the initial state then a state from |3(s) with no incoming edges 
is chosen as the new initial state. Thus, the input automaton is 
expanded to an equivalent automaton in which every state has 60 
a set of incoming edges corresponding to one incoming edge 
in the original automaton. 

The algorithm R then traverses the expanded automaton 
using the input set of trace slices and marks the transitions 
used in the traversal (at lines 3 to 13 of the “main” function). 65 
After all the traces are applied, the unmarked transitions 
(which are not traversed in the trace slice) are removed from 


the expanded automaton to generate a reduced automaton. 
The reduced automaton is then compressed by merging states 
that have the same outgoing transitions and removing those 
states that have no incoming states. At the end, the com- 
pressed automaton is associated with parameter information 
(the combination of parameters associated with the trace slice 
being analyzed) removed when performing the parametric 
trace slicing discussed above. The output of the algorithm R is 
the finite state machines that are the specifications for the 
trace slices. 

The output of the algorithm R can also be input to a regular 
pattern generator that generates equivalent regular patterns 
form the finite state machines. A variety of different well- 
known regular pattern generators can be used with the para- 
metric trace slice mining discussed herein. In one or more 
embodiments, the regular pattern generator uses the well- 
known Brzozowski method. Additional information regard- 
ing the Brzozowski method can be found in, for example, 
“Derivatives of regular expressions”, by J. A. Brzozowski, 
Journal of the Association for Computing Machinery (ACM), 
11(4):48 1-494 (1964). 

Example Computing Device 

FIG. 5 is a block diagram illustrating an example comput- 
ing device 500 in which the parametric trace slicing can be 
implemented in accordance with one or more embodiments. 
Computing device 500 can be used to implement the various 
techniques and processes discussed herein. Computing 
device 500 can be any of a wide variety of computing devices, 
such as a desktop computer, a server computer, a handheld 
computer, a laptop or netbook computer, a personal digital 
assistant (PDA), an internet appliance, a game console, a 
set-top box, a cellular phone, a digital camera, audio and/or 
video players, audio and/or video recorders, and so forth. 

Computing device 500 includes one or more processor(s) 
502, computer readable media such as system memory 504 
and mass storage device(s) 506, input/output (I/O) device(s) 
508. and bus 510. Processor(s) 502 include one or more 
processors or controllers that execute instructions stored in 
system memory 504 and/or mass storage device(s) 506. Pro- 
cessor/s) 502 may also include computer readable media, 
such as cache memory. 

System memory 504 includes various computer readable 
media, including volatile memory (such as random access 
memory (RAM)) and/or nonvolatile memory (such as read 
only memory (ROM)). System memory 504 may include 
rewritable ROM, such as Flash memory. 

Mass storage device(s) 506 include various computer read- 
able media, such as magnetic disks, optical discs, solid state 
memory (e.g.. Flash memory), and so forth. Various drives 
may also be included in mass storage device(s) 506 to enable 
reading from and/ or writing to the various computer readable 
media. Mass storage device(s) 506 include removable media 
and/or nonremovable media. 

I/O device(s) 508 include various devices that allow data 
and/or other information to be input to and/or output from 
computing device 500. Examples of I/O device(s) 508 
include cursor control devices, keypads, microphones, moni- 
tors or other displays, speakers, printers, network interface 
cards, modems, lenses, CCDs or other image capture devices, 
and so forth. 

Bus 51 0 allows processors) 502, system 504, mass storage 
device(s) 506, and I/O device(s) 508 to communicate with 
one another. Bus 510 can be one or more of multiple types of 
buses, such as a system bus, PCI bus, IEEE 1394 bus, USB 
bus, and so forth. 
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Although the description above uses language that is spe- 
cific to structural features and/or methodological acts in pro- 
cesses, it is to be understood that the subject matter defined in 
the appended claims is not limited to the specific features or 
processes described. Rather, the specific features and pro- 5 
cesses are disclosed as example forms of implementing the 
claims. Various modifications, changes, and variations appar- 
ent to those skilled in the art may be made in the arrangement, 
operation, and details of the disclosed embodiments herein. 

to 

What is claimed is: 

1. A method implemented in one or more computing 
devices, the method comprising: 

obtaining a program trace of a program, the program trace 
having been generated using predictive program instru- 15 
mentation and including one or more feasible traces that 
were not part of a program execution from which the 
program trace is generated, the one or more feasible 
traces having been generated based on partial orders of 
events determined at each of multiple predetermined 20 
points during collection of a direct trace of the program; 
traversing events of the program trace; 
identifying, for each event identified in traversing the pro- 
gram trace, a trace slice of which the identified event is 
a part based on one or more parameter instances in the 25 
identified event; 

adding, for each trace slice of which the identified event is 
a part, the identified event to an end of a record of the 
trace slice; 

obtaining one or more trace slices obtained from the pro- 30 
gram trace; 

generating a specification for each of the one or more trace 
slices, each specification comprising a finite state 
machine indicating a maimer in which the program oper- 
ates; and 35 

outputting the specification for each of the one or more 
trace slices. 

2 . A method as recited in claim 1 , wherein the program 

trace is a program trace of a program miming while the 
method is being performed. 40 

3. A method as recited in claim 1, wherein an event having 
no parameter instances is part of all trace slices. 

4 . A method as recited in claim 1 , further comprising main- 
taining a record of trace slices for each possible combination 
of parameter instances in the program trace, the possible 45 
combination of parameter instances being identified based on 
the parameter instances observed while traversing the pro- 
gram trace. 

5 . A method as recited in claim 1 , wherein traversing the 
events of the program trace comprises traversing the program 50 
trace from a first event of the program trace towards a last 
event of the program trace. 

6. A method as recited in claim 1, wherein traversing the 
program trace comprises traversing the program trace one 
time regardless of the number of parametric trace slices that 55 
are obtained from the program trace. 

7. A method as recited in claim 1, further comprising: 
determining, for at least part of the program trace, whether 

a set of constraints for the program trace is complied 
with; and 60 

outputting an indication of whether the set of constraints 
for the program trace is complied with. 

8. A method as recited in claim 1, further comprising moni- 
toring the program trace by: 

maintaining a record of monitor instance states, wherein 65 
each monitor instance state indicates, for a particular set 
of parameter instances, a set of identified events; and 
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maintaining a record of whether each monitor instance 
state complies with one or more constraints on the pro- 
gram trace. 

9 . A method as recited in claim 1 , further comprising: 

generating, for each specification, a regular expression 

equivalent to the specification; and 

outputting the regular expression for each of the one or 
more trace slices. 

10. One or more computer readable memories or non- 
transitory storage devices having stored thereon multiple 
instructions execution of which, by one or more processors of 
a device, causes the one or more processors to: 

obtain a program trace of a program, the program trace 
having been generated using predictive program instru- 
mentation and including one or more feasible traces that 
were not part of a program execution from which the 
program trace is generated, the one or more feasible 
traces having been generated based on partial orders of 
events determined at each of multiple predetermined 
points during collection of a direct trace of the program; 

traverse events of the program trace; 

identify, for each event identified in traversing the program 
trace, a trace slice of which the identified event is a part 
based on one or more parameter instances in the identi- 
fied event; 

add, for each trace slice of which the identified event is a 
part, the identified event to an end of a record of the trace 
slice; 

obtain one or more trace slices obtained from the program 
trace; 

generate a specification for each of the one or more trace 
slices, each specification comprising a finite state 
machine indicating a maimer in which the program oper- 
ates; and 

output the specification for each of the one or more trace 
slices. 

11 . One or more computer readable memories or non- 
transitory storage devices as recited in claim 10, the multiple 
instructions further causing the one or more processors to 
maintain a record of trace slices for each possible combina- 
tion of parameter instances in the program trace, the possible 
combination of parameter instances being identified based on 
the parameter instances observed while traversing the pro- 
gram trace. 

12 . One or more computer readable memories or non- 
transitory storage devices as recited in claim 10, wherein to 
traverse the events of the program trace is to traverse the 
program trace from a first event of the program trace towards 
a last event of the program trace. 

13 . One or more computer readable memories or non- 
transitory storage devices as recited in claim 10, wherein to 
traverse the program trace is to traverse the program trace one 
time regardless of the number of parametric trace slices that 
are obtained from the program trace. 

14 . One or more computer readable memories or non- 
transitory storage devices as recited in claim 10, the multiple 
instructions further causing the one or more processors to: 

determine, for at least part of the program trace, whether a 
set of constraints for the program trace is complied with; 
and 

output an indication of whether the set of constraints for the 
program trace is complied with. 

15 . One or more computer readable memories or non- 
transitory storage devices as recited in claim 10, the multiple 
instructions further causing the one or more processors to 
monitor the program trace by: 
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maintaining a record of monitor instance states, wherein 
each monitor instance state indicates, for a particular set 
of parameter instances, a set of identified events; and 
maintaining a record of whether each monitor instance 
state complies with one or more constraints on the pro- 
gram trace. 

16 . One or more computer readable memories or non- 
transit ory storage devices as recited in claim 10, the multiple 
instructions further causing the one or more processors to: 

generate, for each specification, a regular expression 
equivalent to the specification; and 
output the regular expression for each of the one or more 
trace slices. 

17 . A computing device comprising: 
a processor; and 

one or more computer readable non-transitory media, 
coupled to the processor, to store multiple instructions 
execution of which by the processor causes the proces- 
sor to: 

obtain a program trace of a program, the program trace 
having been generated using predictive program 
instrumentation and including one or more feasible 
traces that were not part of a program execution from 
which the program trace is generated, the one or more 
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feasible traces having been generated based on partial 
orders of events determined at each of multiple pre- 
determined points during collection of a direct trace 
of the program, 

5 traverse events of the program trace, 

identify, for each event identified in traversing the pro- 
gram trace, a trace slice of which the identified event 
is a part based on one or more parameter instances in 
the identified event, 

to add, for each trace slice of which the identified event is 
a part, the identified event to an end of a record of the 
trace slice, 

obtain one or more trace slices obtained from the pro- 
gram trace, 

15 generate a specification for each of the one or more trace 

slices, each specification comprising a finite state 
machine indicating a maimer in which the program 
operates, and 

output the specification for each of the one or more trace 

20 slices. 

18 . A method as recited in claim 1 , wherein the direct trace 
of the program is a trace corresponding to an actual execution 
of the program. 



